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ODETTE File Transfer Protocol 
Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This memo describes a file transfer protocol to facilitate electronic 
data interchange between trading partners. 


The protocol, denoted the ODETTE File Transfer Protocol, supports 
both direct communication between installations and indirect 
communication via a third party clearing centre. It was developed by 
the Organisation for Data Exchange by Tele Transmission in Europe to 
facilitate communication within the European motor industry and is 
presented here to allow for wider use within the Internet community. 
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1. Introduction 
1.1 Background 


The ODETTE File Transfer Protocol (ODETTE-FTP) was defined in 1986 by 
working group four of the Organisation for Data Exchange by Tele 
Transmission in Europe (ODETTE) to address the electronic data 
interchange (EDI) requirements of the European automotive industry. 
It was designed in the spirit of the Open System Interconnection 
(OSI) model utilising the Network Service provided by the CCITT X25 
recommendation. 


Over the last ten years ODETTE-FTP has been widely deployed on 
systems of all sizes from personal computers to large mainframes. As 
a result of the wide scale deployment of internet technology and the 
trend towards global business practices, ODETTE has decided to extend 
the scope of it's file transfer protocol to allow the use of TCP/IP 
and to make the protocol available to the Internet community. 


This memo describes the ODETTE-FTP protocol using the Transmission 
Control Protocol for it's network service. 


1.2 Relationship to the original ODETTE Standard 


This memo is an interpretation of version 1.3 of the ODETTE File 


Transfer Protocol [OFTP]. In the event of any ambiguity between this 
document and the original ODETTE-FTP, the original shall take 
precedence. 


For ODETTE-FTP on TCP/IP the following sections have been added with 
respect to the original document. 


Section 2 - Network Service 
Section 7 - Stream Transmission Buffer 
Appendix A - Virtual File mapping example 
1.3 General Principles 
The aim of the ODETTE-FTP is to facilitate the transmission of a file 
between one or more locations in a way that is independent of the 


data communication network, system hardware and software environment. 


In designing and specifying the protocol, the following factors were 
considered. 


1. The possible differences of size and sophistication (file storage, 
small and large systems). 
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2. The necessity to work with existing systems (reduce changes to 
existing products and allow easy implementation). 


3. Systems of different ages. 
4. Systems of different manufactures. 


5. The potential for growth in sophistication (limit impact and avoid 
changes at other locations). 


1.4 Structure 


ODETTE-FTP is modelled on the OSI reference model. It is designed to 
use the Network Service provided by level 3 of the model and provide 
a File Service to the users. Thus the protocol spans levels 4 to 7 
of model. 


The description of the ODETTE-FTP contained in this memo is closely 
related to the original 'X.25’ specification of the protocol and in 
the spirit of the OSI model describes: 


1. A File Service provided to a user monitor. 


2. A protocol for the exchange of information between peer 
ODETTE-FTP entities. 


A major consideration in adapting the protocol to use the 
Transmission Control Protocol (TCP) was the desire to make no changes 
to the existing protocol by adding the functionality required to 
allow implementors to support internet communication with only minor 
changes to existing ODETTE-FTP engines. To this end an additional 
header has been added to the start of each exchange buffer to allow 
the TCP byte stream to be broken up into the discrete exchange 
buffers expected by the ODETTE-FTP protocol. 


1.5 Virtual Files 
Information is always exchanged between ODETTE-FTP entities ina 
standard representation called a Virtual File. This allows data 


transfer without regard for the nature of the communicating systems. 


The mapping of a file between a local and virtual representation will 
vary from system to system and is not defined here. 


Nash Informational [Page 4] 


RFC 2204 ODETTE File Transfer Protocol September 1997 
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(O ss ee o o----+----0 
| Local | Site Site | Local | 
| FileB | B c | Filec | 
C a o OASIS o 


A Virtual File is described by a set of attributes identifying and 
defining the data to be transferred. The main attributes are: 


1.5.1 Organisation: 
Sequential 


Logical records are presented one after another. The ODETTE-FTP 
must be aware of the record boundaries. 


1.5.2 Identification 
Dataset Name 


Dataset name of the Virtual File being transfered, assigned by 
bilateral agreement. 
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Time stamp (HHMMSS) 


A file qualifier indicating the time the Virtual File was made 
available for transmission. 


Date stamp (YYMMDD) 


A file qualifier indicating the date the Virtual File was made 
available for transmission. 


The Dataset Name, Date and Time attributes are assigned by a Virtual 
File’s Originator and are used to uniquely identify the file. They 
must not be changed by intermediate locations. 
The Date attribute represents the decade and year in a two digit 
field. Since the ODETTE-FTP only uses this information to identify a 
particular Virtual File it will continue to operate correctly in the 
year 2000 and beyond. 
The User Monitor may use the Virtual File Date attribute in local 
processes involving date comparisons and calculations. Any such use 
falls outside the scope of this protocol and year 2000 handling is a 
local implementation issue. 
1.5.3 Record Format 
Four record formats are defined. 
Fixed (F) 
Each record in the file has the same length. 
Variable (V) 
The records in the file can have different lengths. 
Unstructured (U) 
The file contains a stream of data. No structure is defined. 
Text File (T) 
A Text File is defined as a sequence of ASCII characters, 


containing no control characters except CR/LF which delimits 
lines. A line will not have more than 2048 characters. 
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1.5.4 Restart 


ODETTE-FTP can negotiate the restart of an interrupted Virtual File 
transmission. Fixed and Variable format files are restarted on 
record boundaries. For Unstructured and Text files the restart 
position is expressed as a file offset in 1K (1024 octet) blocks. 
The restart position is always calculated relative to the Virtual 
File. 


1.6 Service Description 
ODETTE-FTP provides a file transfer service to a user monitor and in 


turn uses the Internet transport layer stream service to communicate 
between peers. 


These services are specified in this memo using service primitives 
grouped into four classes as follows: 


Request (RQ) An entity asks the service to do some work. 
Indication (IND) A service informs an entity of an event. 
Response (RS) An entity responds to an event. 

Confirm (CF) A service informs an entity of the response. 


Services may be confirmed, using the request, indication, response 
and confirm primitives, or unconfirmed using just the request and 
indication primitives. 


2. Network Service (TCP Transport Service) 
2.1 Introduction 


ODETTE-FTP peer entities communicate with each other via the OSI 
Network Service or the Transmission Control Protocol Transport 
Service [TCP]. This is described by service primitives representing 
request, indication, response and confirmation actions. 


For the internet environment, the service primitives mentioned below 
for the Network Service have to be mapped to the respective Transport 
Service primitives. This section describes the network service 
primitives used by ODETTE-FTP and their relationship to the TCP 
interface. In practice the local transport service application 
programming interface will be used to access the TCP service. 


2.2 Service Primitives 


All Network primitives can be directly mapped to the respective 
Transport primitives when using TCP. 
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2.2.1 Network Connection 


N_CON_RQ = ------ > N_CON_IND 
N_CON_CF <------ N_CON_RS 


This describes the setup of a connection. The requesting ODETTE-FTP 
peer uses the N_CON_RO primitive to request an active OPEN of a 
connection to a peer ODETTE-FTP, the Responder, which has previously 
requested a passive OPEN. The Responder is notified of the incoming 
connection via N_CON_IND and accepts it with N_CON_RS. The requester 
is notified of the completion of it’s OPEN request upon receipt of 


_CON_CF. 

Parameters 

Request Indication Response Confirmation 
Dest addr ------> same ame ame 


2.2.2 Network Data 
N_DATA_ RO = ------ > N_DATA_IND 


Data exchange is an unconfirmed service. The Requester passes data 
for transmission to the network service via the N_DATA_RQ primitive. 
The Responder is notified of the availability of data via N_DATA_IND. 
In practice the notification and receipt of data may be combined, 
such as by the return from a blocking read from the network socket. 


Parameters 
Request Indication 
Data. === 5235722232722 > same 


2.2.3 Network Disconnection 
N_DISC_RQ ------ > N_DISC_IND 
An ODETTE-FTP requests the termination of a connection with the 
N_DISC_RO service primitive. It’s peer is notified of the CLOSE by a 


N_DISC_IND event. It is recognised that each peer must issue a 
N_DISC_RO primitive to complete the TCP symmetric close procedure. 
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2.2.4 Network Reset 
------ > N_RST_IND 
An ODETTE-FTP entity 
event. It should be 
a peer RESETTING the 


is never sent to the 


2.3 Port Assignment 


is notified of a network error by a N_RST_IND 
noted that N_RST_IND would also be generated by 
connection, but this is ignored here as N_RST_RO 
Network Service by ODETTE-FTP. 


A ODETTE-FTP requester will select a suitable local port. 


The responding ODETTE-FTP will listen for connections on Registered 


Port 3305, the service name is ’odette-ftp’. 


3. File Transfer Service 


The File Transfer Service describes the services offered by an 


ODETTE-FTP Entity to 


it’s User Monitor. The implementation of the 


service primitives is a local matter. 


Nash 
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3.1 Model 
O===+=+2 === === o Onn SaaS essa HH == o 
| | | 
| USER MONITOR | | USER MONITOR | 
| | 
Ones = See na ee o E E o 
| A | A 
is a FILE TRANSFER SERVICE a Oa 
F_XXX_RO/RS | | F_XXX_IND/CF F_XXX_RO/RS | | F_XXX_IND/CF 
vo | v | 
o a ae ee o QSPRS == Sea SS o 
|- ----- >| | 
| ODETTE-FTP Entity | E-Buffer | ODETTE-FTP Entity | 
lá === -=- | | 
aa O a ra o O =P TE OSA o 
| A | A 
N_XXX_RQ/RS | | N_XXX_IND/CF N_XXX_RQ/RS | | N_XXX_IND/CF 
| | | 
Sacra ed ayes | es ewadiad: NETWORK OR RU TCHS laa 
v | v | 
OF Stedet 22 ose tooo So E o 
| | 
| NETWORK | 
| | 
O E RE Ó o 
Key: E-Buffer - Exchange Buffer 
F - File Transfer Service Primitive 


N — Network Service Primitive 
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3.2 Session Setup 


3.2.1 Session Connection Service 


F_CONNECT_RQ ---->|------------ |----> F_CONNECT_IND 
F_CONNECT_CF <----|------------ |<---- F_CONNECT_RS 
Parameters 
Request Indication Response Confirm 


called-address -> same --- eee 
calling-address-> same --- DE 


EDIL. «==++++2 Hse > same TD2-=+2+2=+23 == > same 
PSWl=====3====== > same PSW2. ========+== > same 
tiodel.===2=23235 > 'mode2. === aE > mode! =->=2228+3= > same 
restartl. ======= > Same. ====8: 235235 > LestartZ ======= > same 
Mode 


Specifies the file transfer capabilities of the entity sending or 
receiving a F_CONNECT primitive for the duration of the session. 


Value: 
Sender-Only The entity can only send files. 
Receiver-Only The entity can only receive files. 
Both The entity can both send and receive files. 
Negotiation: 
Sender-Only Not negotiable. 
Receiver-Only Not negotiable. 
Both Can be negotiated down to Sender-Only or 


Receiver-Only by the User Monitor or the 
ODETTE-FTP entity. 


Nash Informational [Page 11] 


RFC 2204 ODETTE File Transfer Protocol September 1997 


Request Indication Response Confirm 
Sender-only ----> Receiver-only --> Receiver-only --> Sender-only 
Receiver-only --> Sender-only ----> Sender-only ----> Receiver-only 
Both: ===== PTRS > Both «====P====== > Bothi == ===+===28= > Both 
| or +------ > Receiver-only --> Sender-only 
or +------ > Sender-only ----> Receiver-only 
or ===- > Receiver-only --> Receiver-only --> Sender-only 
or +----- > Sender-only ----> Sender-only ----> Receiver-only 
Restart 


Specifies the file transfer restart capabilities of the User 


Monitor. 
Value: 
Negotiation: 
Request Indication Response Confirm 
A A A ayo aar ee 
or +-> restart = N ----> restart = N 
restart = N ----> restart = N ----> restart = N ----> restart = N 
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3.3 File Transfer 
3.3.1 File Opening 
F_START_FILE_RQ ---->|------------ |----> F_START_FILE_IND 
F_START_FILE_CF(+|-) <----|------------ |<---- F_START_FILE_RS(+]|-) 
Parameters: 
Request Ind RS (+) CF (+) RS (-) CF (-) 
file-name ----> same ==5= === == ++ =P 
date-time ----> same Saa eon ==-- ana 
destination---> same SSS SS A ERTE 
originator----> same zamn snes Bese szesz 
rec-format----> same Faas ine aegis Fee 
rec-size ----- > same ===> === == 55 ==== 
file-size----- > same I= Sats aa 2 
restart-posl--> same-> restart-pos2-> same A RSRS 
==-- ==-- SESS Sans cause ------ > same 
=== === ==> ===2 retry-later-> same 
Notes: 
1. Retry-later has values "Y" or "N". 2. Cause is the reason for 
refusing the transfer (1,..,13,99). 3. Restart-posl not equal 0 is 
only valid if restart has been agreed 
during initial negotiation. 

4. Restart-pos2 is less than or equal to restart-posl. 

3.3.2 Data Regime 

F_DATA RO ---->|------------ |----> F_DATA_IND 
Notes: 
1. The data format within a F_DATA primitive is locally defined. 
2. The File Transfer service may have to provide a flow control 
mechanism to regulate the flow of F_DATA primitives. 
Nash Informational [Page 13] 


RFC 2204 ODETTE File Transfer Protocol September 1997 


3.3.3 File Closing 


E-CLOSE- FTE O RO: ===> +23322=32558 aaa > F_CLOSE_FILE_IND 

F_CLOSE_FILE_CF(+|-) <---|------------ |<---- F_CLOSE_FILE_RS(+|-) 
Parameters 

Request Ind RS (+) CF (+) RS (-) CF (-) 
rec-count ---> same Sras Sane Sas Sane 
unit-count --> same a aia an So => 
o E Speaker=Y ---> Speaker=N ---- ES 
Sr === Speaker=N ---> Speaker=Y ---- == 
=== SaaS SaaS Sano cause ---> same 


In a positive Close File response (F_CLOSE_FILE_RS(+)) the current 
Speaker may either: 


1. Set Speaker to "Yes" and become the Speaker. 2. Set Speaker 
to "No" and remain the Listener. 


The File Transfer service will ensure that the setting of the speaker 
parameter is consistent with the capabilities of the peer user. 


The turn is never exchanged in the case of a negative response or 
confirmation. 


Only the Speaker is allowed to issue F_XXX _FILE_RO primitives. 
3.3.4 Exchanging the Turn 
3.3.4.1 Initial Turn (First Speaker) 
The Initiator becomes the first Speaker at the end of the Session 
Setup (F_CONNECT_CF received by Initiator and F_CONNECT_RS sent by 
Responder). 
3.3.4.2 Following Turns 
Rules: 


1. At each unsuccessful End of File the turn is not exchanged. 


2. At each successful End of File the turn is exchanged if requested 
by the Listener: 
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- The current Listener receives F_CLOSE_FILE_IND 
(Speaker = choice). 


- If the Listener answers F_CLOSE_FILE_RS(Speaker = YES), it 
becomes Speaker, the Speaker receives F_CLOSE_FILE_CF (Speaker = 
NO) and becomes Listener. 


- If the Listener answers F_CLOSE_FILE_RS (Speaker = NO), it 
remains Listener, and the Speaker receives F_CLOSE_FILE_CF 
(Speaker = YES) and remains Speaker. 


3. The Speaker can issue a Change Direction request (F_CD_RQ) to 
become the Listener. The Listener receives a Change Direction 
indication (F_CD_IND) and becomes the Speaker. 


4. In order to prevent loops of F_CD_RO/IND, it is an error to send 
F_CD_RO immediately after having received a F_CD_IND. 


3.3.5 End to End Response 
This service is initiated by the current Speaker (if there is no file 


transfer in progress) to send an End-to-End response from the final 
destination to the originator of a file. 


F_EERP_RQ ---->|------------ |----> F_EERP_IND 

Parameters 

Request Indication 

filename ------- > same 

daten==========S > same 

time === > same 

destination ----> same 

originator ----- > same 


Relationship with Turn: 

- Only the Speaker may send an End to End Response request. 

- Invoking the EERP service does not change the turn. 

- If a F_CD_IND has been received just before F_EERP_RO is issued, 
this results in leaving the special condition created by the 


reception of F_CD_IND; i.e. while it was possible to issue 
F_RELEASE_RO and not possible to issue F_CD_RO just after the 
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3. 


3% 


3. 


reception of F_CD_IND, after having issued F_EERP_RQ the normal 
Speaker status is entered again (F_CD_RQ valid, but F_RELEASE_RQ 
not valid). 


4 Session Take Down 


4.1 Normal Close 


F_RELEASE_RQ ---->|------------ ----> F_RELEASE_IND 
Parameters 
Request Indication 
reason = normal ------- > ---- 


The Release service can only be initiated by the Speaker. 


The Speaker can only issue a Release request (F_RELEASE_RQ) just 
after receiving an unsolicited Change Direction indication 
(F_CD_IND). This ensures that the other partner doesn’t want to send 
any more files in this session. 


Peer ODETTE-FTP entities action a normal session release by 
specifying Reason = Normal in an End Session (ESID) command. 


4.2 Abnormal close 


F_RELEASE_RQ ---->|------------ |----> F_ABORT_IND 
Parameters 
Request Indication 
reason = error value --> same (or equivalent) 
AO (Abort Origin) = (L)ocal or (D)istant 


Abnormal session release can be initiated by either the Speaker or 
the Listener and also by the user or provider. 


Abnormal session release can occur at any time within the session. 
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Peer ODETTE-FTP entities action an abnormal session release by 
specifying Reason = Error-value in an End Session (ESID) command. 


The abnormal session release deals with the following types of error: 


Tz 


The service provider will initiate an abnormal release in the 
following cases: 


1. Protocol error, 2. Failure of the Start Session (SSID) 
negotiation, 3. Command not recognised, 4. Exchange buffer size 
error, 5. Resources not available, 6. Other unspecified abort code 
(with "REASON" = unspecified). 


The User Monitor will initiate an abnormal release in the 
following cases: 


1. Local site emergency close down, 2. Resources not available, 3. 
Other unspecified abort code (with "REASON" = unspecified). 


Other error types may be handled by an abort of the connection. 


BEA Abort 

F_ABORT_RQ ---->|------------ |----> F_ABORT_IND 
User Initiated Abort 
F_ABORT_IND <----|------------ |----> F_ABORT_IND 
Provider Initiated Abort 

Parameters 

Request Indication 

- R (Reason): specified or unspecified 

= AO (Abort Origin): (L)ocal or (D)istant 


The Abort service may be invoked by either entity at any time. 


The service provider may initiate an abort in case of error 
detection. 


Nash 
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3.4.4 Explanation of Session Take Down Services 


User | OFTP | Network | OFTP | User 


1. Normal Release 


F_RELEASE_RO 


A yy 


=> 
(R=normal) | | | | 


| ESID (R=normal) 


2. User Initiated Abnormal Release 


F_RELEASE_RO F_ABORT_IND 


| ESID (R=error) 


Kos ee aS 
(R=error value) | | | | (R=error, AO=D) 
User | OFTP | Network | OFTP | User 

3. Provider Initiated Abnormal Release 
F_ABORT_IND | | ESID(R=error) | | F_ABORT_IND 
PEL io —* * 


4. User Initiated Connection Abort 


F_ABORT_RO N_DISC_RO F_ABORT_IND 
* —-—----------- -> --|--------- >. .---------- -> --|-------------- > 
| | N_DISC_IND | | (R=unsp.,AO=D) 
5. Provider Initiated Connection Abort 
F_ABORT_IND | | N_DISC_RO | | F_ABORT_IND 
Pasate ena A Sy onto |-> --|-------------- > 
(R=error,AO=L) | | N_DISC_IND | | (R=unsp.,AO=D) 
Key: * Origin of command flow 
F_---> File Transfer Service primitive 
N_ ---> Network Service primitive 


===> ODETTE-FTP (OFTP) protocol message 
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This state automata defines the service as viewed by the User 


Monitor. 


Events causing a state transition are shown in lower case 


and the resulting action in upper case where appropriate. 


ESTA 


Nash 


1 


Idle State Diagram 
ore E 
decision | 

Ho | IDLE 
| F_CONNECT_RQ | (0) 
| DET 
v 

p==========2S====== o 

I_WF_FCONNECTCF 

| | 

0=S= SRA Hass O 
| 
| F_CONNECT_CF 
v 

O == 22222 > o 

| | 

| IDLE SPEAKER | 

| (1) | 

| See Speaker | 

State Diagram 
aaa ae o 
Informational 


IDLE LISTENER 
(2) 

See Listener 

State Diagram 
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3.5.2 Speaker State Diagram 
a See o UTE ic o 
IDLE LISTENER IDLE 
CD_RQ just sent see (0) 
| see (3), Listen | | Idle | 
| State Diagram | | State Diagram | 
O += SEARS o 03325355539 3== 253555 o 
A A 
| | 
decision decision decision 
F_CD_RQ Ho + F_RELEASE_RO 
| | F_EERP_RQ | | 
o o | O En A E SaaS o 
| | <------------- + | IDLE SPEAKER | 
| IDLE SPEAKER | | (4) 
(1) decision CD_IND 
A ela a A E ee just received 
O O F_EERP_RO 0352559535255 O 
A A | | 
TER | decision and P1 decision and P1 | 
| | +----------------- + Ho + 
F_START_FILE_RO | | F_START_FILE_RQ 
V V 
ln rn o 
| |  £_file start_cf(-) | | 
| +---------------------- | OPENING | 
| | | 
| an aaa o 
f file _close_cf(-) f_start_file cf (+) 
and not P2 | 
| V 
On Saat aHtneensHo o A o 
a — — [iii + 
CLOSING DATA TRANSFER record to send | 
| | | [<----------------- + 
Or SH ===> O e A O F_DATA_RO 
| A | 
| | end of file | 
AE E + 
| F_CLOSE_FILE_RO 
| O E o 
| f_close_file(+) and P2 | IDLE LISTENER | 
E SAA eee >| see (2), Listen | 
| State Diagram | 
Predicates: C o 
P1: Mode = Both or (Mode = Sender-Only) 
P2: Negative confirmation or (positive confirmation, Speaker = YES) 
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3.5.3 Listener State Diagram 


IDLE SPEAKER IDLE 
CD_IND just 


| received see(4) | | see (0) | 
| Speaker State | | Idle | 
| Diagram | | State Diagram | 
Oe a te a o) O eh A E a o 
A A 
| | 
decision f_eerp_ind decision 
F_CD_IND +-------------- + F_RELEASE_IND 
| | | | 
o o | (o aA n a RÓS o 
| |< SSS SSS + f_eerp_ind | 
<----------------------------- IDLE LISTENER 
| IDLE LISTENER | (3) 
| | f_start_file_ind | CD_RQ | 
| (2) | and not p2 | just sent | 
A ae ig yd ale taal ate as + 
o o F_START_FILE_RS(-) | o----------------- o 
A A A | 
| | +----------------------- + 
Ml a | | | 
| | | f_start_file_ind and not p2 | 
|| 4es5---2------------=---------- + | 
| | F_START_FILE_RS (-) | 
| | f_start_file_ind f_start_file_ind | 
| | and p2 and p2 | 
| +------------------------------- + +------------------ + 
| F_START_FILE_RS(+) | | F_START_FILE_RS (+) 
| v v 
Osa GASA o 
f close _file ind and not pl | DATA | ------------- + 
HO | TRANSFER 
F_CLOSE_FILE_RS (-) | |<------------ + 
o--------------- o F_DATA_IND 
0-= === === o | 
IDLE SPEAKER f_close_file_ind and p1 | 
see (1), Spkr |<-------------------------- + 
| State Diagram | F_CLOSE_FILE_RS (+) 
OS ge age op ae O 
Predicates: 


Pl: (decision to send F_CLOSE_FILE_RS(+)) and 
(decision to set Speaker = yes in F_CLOSE_FILE_RS (+) ) 
P2: (decision to send F_START_FILE_RS (+) ) 
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4. Protocol Specification 


4.1 Overview 


The ODETTE-FTP protocol is divided into five operating phases. 


Start Session 
Start File 
Data Transfer 


End File 


End Session 


After the End File phase an ODETTE-FTP entity may enter a new Start 
File phase or terminate the session via the End Session phase. 


ODETTE-FTP peers communicate by sending and receiving messages in 
Exchange Buffers via the Network Service. Each Exchange Buffer 
contains one of the following commands. 


SSRM Start Session Ready Message 
SSID Start Session 
SFID Start File 
SFPA Start File Positive Answer 
SFNA Start File Negative Answer 
DATA Data 
CDT Set Credit 
EFID End File 
EFPA End File Positive Answer 
EFNA End File Negative Answer 
ESID End Session 
CD Change Direction 
EERP End to End Response 
RTR Ready To Receive 

The remainder of this section describes the protocol flows. Section 


five details the command formats. 


4.2 Start Session Phase 


The Start Session phase is entered immediately after the network 
connection has been established. 


4.2.1 Entity Definition 


The ODETTE-FTP entity that took the initiative to establish the 


network connection becomes the Initiator. It’s peer becomes the 
Responder. 
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4.2.2 Protocol Sequence 


The first message must be sent by the Responder. 


1. Initiator <-------------— SSRM -- Responder Ready Message 
ES y SSID asso pS ssa > Identification 
LK SSID -- Identification 


4.3 Start File Phase 

4.3.1 Entity Definition 
The Initiator from the Start Session phase is designated the Speaker 
while the Responder becomes the Listener. The roles are reversed by 


the Speaker sending a Change Direction command to the Listener. 


4.3.2 Protocol Sequence 


1. Speaker -- SFID ------------ > Listener Start File 
LISTS SS SS SFPA -- Answer YES 
2. Speaker -- SFID ------------ > Listener Start File 
KS= += HP RSS > SFNA -- Answer NO 

Go To 1 


Note: The User Monitor should take steps to prevent a loop 
situation occurring. 


2. Speaker -- CD -------------- > Listener Change Direction 
Listener <------------ EERP -- Speaker End to End Response 
== RTR ----========- > Ready to Receive 
KRIS TRE SFID -- Start File 


4.3.3 Restart Facilities 
The Start File command includes a count allowing the restart of an 
interrupted transmission to be negotiated. If restart facilities are 
not available the restart count must be set to zero. The sender will 
start with the lowest record count + 1. 

4.3.4 Broadcast Facilities 


The destination in a Start File command can be specified as follows. 


1. An explicitly defined destination. 
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2. A group destination that allows an intermediate location to 
broadcast the Virtual File to multiple destinations. 


The Listener will send a negative answer to the Speaker when the 
destination is not known. 


4.3.5 Priority 


The prioritisation of files for transmission is left to the local 
implementation. To allow some flexibility, a change direction 
mechanism is available in the End File phase. 


4.3.6 End To End Response (EERP) 


The End to End Response (EERP) command notifies the originator of a 
Virtual File that it has been successfully delivered to it’s final 
destination. This allows the originator to perform house keeping 
tasks such as deleting copies of the delivered data. 


A Response Command must be sent from the location performing the 
final processing or distribution of the data to the originator. The 
Response is mandatory and may be sent in the same or in any 
subsequent session. 


When an intermediate location broadcasts or distributes a Virtual 
File it must receive a Response command from all the locations to 
which it forwarded the data before sending it’s own Response. This 
ensures that the Response received by the Virtual File’s originator 
accounts for all the destination locations. An intermediate location 
therefore needs to track the status of files it processes over time. 


Example: Point to Point 


Location A sends file Ba to Location B which will send an EERP to 
location A after it successfully receives the file. 


O=+===2===5 o 05========2 o 
| Loc. A |----------- S1 ---------- >| Loc. B | 
| | | | 
| [Ba] [$i Rô ncen | [Ba] | 
F SRRA TARRE o ag aaa o 
Key: 
S - File Transfer R - Response EERP [Ba] - File for B from A 


Nash Informational [Page 24] 


RFC 2204 ODETTE File Transfer Protocol September 1997 


Example: Data distribution 


Location A sends a Virtual File containing data for distribution to 
locations B and C via clearing centres El and E2. Clearing centre El 
must wait for a response from E2 (for file Ba) and location C before 
it sends it’s response, R8, to location A. Clearing centre E2 can 
only send response R7 to El when location B acknowledges file Ba with 
response R6. 


OSTRAS o UA o USAS SFE o OA o 
| Loc. A |-- s1 ->| Loc. El |-- S2 ->| Loc. E2 |-- s5 ->| Loc. B | 
| | | | | | 
| [Ba,Ca] |<- R8 --| [Ba,Ca] |<- R7 --| [Ba] |<- R6 --| [Ba] | 
ARPA RR o O + RSE o) SSA ER o OATES o 
a | 
| US RAR o 
+----- 83 ->| Loc. € | 
| | 
+--------- R4 --| [Ca] | 
GSS Ss i sas o 


Example: Data collection 


Locations A and B send files Ca and Cb to clearing centre El which 
forwards both files to location C in a single Virtual File. When it 
receives response R4 from C, clearing centre El sends response R5 to 
location A and R6 to location B. 


ORS == 52555 o (o === 5HE= o OEP o 
| Loc. A |-- S1 ->| Loc. El |-- s3 ->| Loc. c | 
| 
| [Ca] |<- R5 --| [Ca,Cb] |<- R4 --| [Ca,Cb] | 
9as=== === o o =S9S5=S o pa======3= o 
A 

Da =P 2 o | 
| Loc. B |-- $2 ----- + | 

| | 
| [Cb] |<- R6 --------- + 
Oa o 


.7 Ready To Receive Command (RTR) 


In order to avoid congestion between two adjacent nodes caused by a 
continuous flow of EERP’s, a Ready To Receive (RTR) command is 
provided. The RTR acts as an EERP acknowledgement for flow control 
but has no end-to-end significance. 
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Speaker -- EERP ------------ > Listener End to End Response 
LO RTR -- Ready to Receive 
=- EERP ------------ > End to End Response 
LO RTR -- Ready to Receive 
=="SETD === S5>===59>3%8= > Start File 
or 
== (CDi 5==>3 555 S====5 > Exchange the turn 


After sending an EERP, the Speaker must wait for an RTR before 
sending any other commands. 


4.4 Data Transfer Phase 


Virtual File data flows from the Speaker to the Listener during the 
Data Transfer phase which is entered after the Start File phase. 


4.4.1 Protocol Sequence 


To avoid congestion at the protocol level a flow control mechanism is 
provided via the Credit (CDT) command. 


A Credit limit is negotiated in the Start Session phase, this 
represents the number of Data Exchange Buffers that the Speaker may 
send before it is obliged to wait for a Credit command from the 
Listener. 


The available credit is initially set to the negotiated value by the 
Start File positive answer, which acts as an implicit Credit command. 
The Speaker decreases the available credit count by one for each data 
buffer sent to the Listener. 


When the available credit is exhausted, the Speaker must wait for a 
Credit command from the Listener otherwise a protocol error will 


occur and the session will be aborted. 


The Listener should endeavour to send the Credit command without 
delay to prevent the Speaker blocking. 


1. Speaker -- SFID ------------ > Listener Start File 
(== SS SFPA -- Answer YES 
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2. If the Credit Value is set to 2 


Speaker -- Data ------------ > Listener Start File 
== Data w-—- +assa esse > 
Ss === === == CDT == Set Credit 
=- “Data, Ss HsS tae Hssa= > 
-- EFID ------------ > End File 


4.5 End File Phase 
4.5.1 Protocol Sequence 


The Speaker notifies the Listener that it has finished sending a 

Virtual File by sending an End File (EFID) command. The Listener 
replies with a positive or negative End File command and has the 

option to request a Change Direction command from the Speaker. 


1. Speaker -- EFID ------------ > Listener End File 
Aaron EFPA -- Answer YES 
2. Speaker -- EFID ------------ > Listener End File 
GPRS AA EFPA -- Answer YES + CD 
== CD) SHS ene > Change Direction 
Listener <------------ EERP -- Speaker End to End Response 
HARTA RARA RTR -> Ready to Receive 


Go to Start File Phase 
3. Speaker -- EFID ------------ > Listener End File 
a EFNA -- Answer NO 
4.6 End Session Phase 
4.6.1 Protocol Sequence 


The Speaker terminates the session by sending an End Session (ESID) 


command. 
1. Speaker -- EFID ------------ > Listener End File 
LES sarees EFPA -- Answer YES 
== ¡CD =+========523== > Change Direction 
Listener <------------ ESID -- Speaker End Session 
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4.7 Problem Handling 


Error detection and handling should be done as close as possible to 
the problem. This aids problem determination and correction. Each 
layer of the reference model is responsible for it’s own error 
handling. 


ODETTE-FTP can detect protocol errors through the construction of 
it’s state machine, and uses activity timers to detect session hang 
conditions. These mechanisms are separate from the End to End 
controls. 


4.7.1 Protocol Errors 


If a protocol error occurs the session will be terminated and 
application activity aborted. Both locations enter the IDLE state. 


4.7.2 Timers 
To protect against application and network hang conditions ODETTE-FTP 
uses activity timers for all situations where a response is required. 
The timers and actions to be taken if they expire are described in 
section 8, the Protocol State Machine. 

4.7.3 Clearing Centres 
The use of clearing centres introduces the possibility of errors 
occurring as a result of data processing activities within the 
centre. Such errors are not directly related to ODETTE-FTP or the 
communication network and are therefore outside the scope of this 
specification. 

5. Commands and Formats 
ODETTE-FTP entities communicate via Exchange Buffers. The Command 
Exchange Buffers are described below. Virtual File data is carried 
in Data Exchange Buffers which are described in Section 6. 

5.1 Conventions 

5.1.1 Representation unit: 
The basic unit of information is an octet, containing eight bits. 


5.1.2 Values and Characters: 


The ISO 646 IRV 7-bit coded character set [ISO-646] is used to encode 
constants and strings within command exchange buffers. 
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5.2 Commands 


A Command Exchange Buffer contains a single command starting at the 
beginning of the buffer. Commands and data are never mixed within an 
Exchange Buffer. Each command has a fixed length and can not be 
compressed. 

Components: 


1. Command identifier: 


The first octet of an Exchange Buffer is the Command Identifier 
and defines the format of the buffer. 


2. Parameter(s): 


Command parameters are stored in fixed fields within a Command 
Exchange Buffer. All values are required. 


5.3 Command Formats 


The ODETTE-FTP commands are described below using the following 
definitions. 


Position (Pos.) 


Field offset within the command exchange buffer, relative to a 
zero origin. 


Field 
The name of the field. 
Description 


A description of the field. 


Format 
F - A field containing fixed values. All allowable values for 
the field are enumerated in the command definition. 
V - A field with variable values within a defined range. For 
example the SFIDFSIZ field may contain any integer value 
between 0000000 and 9999999. 
X(n) - An alphanumeric field of length n octets. 
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9(n) - A numeric field of length n octets. 
All attributes are in character format. 


A String contains alphanumeric characters from the following set: 


The numerals: 0 to 9 
The upper Case letters: A to Z 
The following special set: /- . 8 ( ) space. 


Space is not allowed as an embedded character. 


Numeric fields are always right justified and left padding with 
zeros must be done when needed. 


5.3.1 SSRM - Start Session Ready Message 


On RSSS STE SHS ER o 
| SSRM Start Session Ready Message 
| Start Session Phase Initiator <---- Responder 

Pos | Field | Description | Format 
|----- +----------—- $ $--------- | 
| 0 | SSRMCMD | SSRM Command, ‘I’ | F x(1) | 
| 1 | SSRMMSG | Ready Message, 'ODETTE FTP READY ’ | E xX(17) | 
| 18 | SSRMCR | Carriage Return | F X(1) | 
NN o 
SSRMCMD Command Code Character 

Value: '1” SSRM Command identifier. 
SSRMMSG Ready Message String(17) 

Value: ’ODETTE FTP READY ” 

SSRMCR Carriage Return Character 


Value: Character with hex value ’0D’ or ’8D’. 
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SSIDCMD 


Value: 


SSIDLEV 


Value: 


SSIDCODE 


Format: 


SSIDPSWD 
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Start Session 


A A E E E E A EE E o 
SSID Start Session 
Start Session Phase Initiator <---> Responder 
Field | Description | Format | 
=- a ie 
SSIDCMD | SSID Command 'X” | F X(1) 
SSIDLEV | Protocol Release Level | F 9(1) | 
SSIDCODE | Initiator’s Identification Code | v x(25) | 
SSIDPSWD | Initiator’s Password | v x(8) | 
SSIDSDEB | Exchange Buffer Size | v 9(5) | 
SSIDSR | Send / Receive Capabilities (S/R/B) | E x(1) | 
SSIDCMPR Compression Indicator (Y/N) F X(1) 
SSIDREST Restart Indicator (Y/N) F X(1) 
SSIDSPEC | Special Logic Indicator (N) | F X(1) 
SSIDCRED | Credit | v 9(3) 
SSIDRSV1 | Reserved | F X(5) | 
SSIDUSER | User Data | v x(8) | 
SSIDCR | Carriage Return | EX1) | 
EE OEE E E E tie e o 

Command Code Character 

“X” SSID Command identifier. 

Protocol Release Level Numeric (1) 

‘1’ ODETTE-FTP protocol release level 1. 

Future release levels will have higher numbers. The 


protocol release level is negotiable, with the lowest level 
being selected. 


Initiator’s Identification Code String (25) 
See Identification Code (Section 5.4) 


Uniquely identifies the Initiator (sender) participating 
in the ODETTE-FTP session. 


Password String (8) 


Key to authenticate the sender. Assigned by bilateral 
agreement. 
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Minimum: 
Maximum: 


SSIDSR 


SSIDCMPR 


Value: 


Value: 


SSIDREST 


Value: 


SSIDSPEC 
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Exchange Buffer Size Numeric (5) 


128 
99999 


The length, in octets, of the largest Exchange Buffer that 
can be accepted by the location. The length includes the 
command octet but does not include the Stream Transmission 
Header. 

After negotiation the smallest size will be selected. 

Send / Receive Capabilities Character 
'S’ Location can only send files. 

"RY Location can only receive files. 


‘B’ Location can both send and receive files. 


Sending and receiving will be serialised during the 
session, so parallel sessions will not take place. 


An error occurs if adjacent locations both specify the send 
or receive capability. 


Compression Indication Character 


Y! The location can handle compressed data. 
/N' The location can not handle compressed data. 


Compression is only used if supported by both locations. 
The compression mechanism is described in Section 6.2 


Restart Indication Character 

'Y’ The location can handle the restart of a partially 
transmitted file. 

'N’ The location can not restart a file. 

Special Logic Indication Character 


'N’ Only valid value for TCP. 


The Special Logic extensions are only useful in an X.25 
environment and are not supported for TCP/IP. 
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SSIDCRED Credit Numeric (3) 
Maximum: 999 
The number of consecutive Data Exchange Buffers sent by the 
Speaker before it must wait for a Credit (CDT) command from 


the Listener. 


The credit value is only applied to Data flow in the Data 
Transfer phase. 


The Speaker’s available credit is initialised to SSIDCRED 
when it receives a Start File Positive Answer (SFPA) 
command from the Listener. It is zeroed by the End File 
(EFID) command. 
After negotiation, the smallest size must be selected in 
the answer of the Responder, otherwise a protocol error 
will abort the session. 
Negotiation of the "credit-window-size" parameter. 
Window Size m -- SSID ------------ > 
Kee SSSS Sees SSID -- Window Size n 
(n less or equal m) 
Note: negotiated value will be "n". 
SSIDRSV1 Reserved String (5) 
This field is reserved for future use. 
SSIDUSER User Data String (8) 
May be used by the ODETTE-FTP in any way. If unused it 
should be initialised to spaces. It is expected that a 
bilateral agreement exists as to the meaning of the data. 


SSIDCR Carriage Return Character 


Value: Character with hex value ’0D’ or ’8D’. 
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5.3.3 SFID - Start File 


O Se SB ee ee eee o 
SFID Start File 

| Start File Phase Speaker ----> Listener 

| Pos | Field | Description | Format | 

|----- +----------- +------------------------------------- +--------—- | 

0 SFIDCMD SFID Command, ’H’ F X(1) 
1 SFIDDSN Virtual File Dataset Name V X(26) 

| 27 | SFIDRSV1 | Reserved | F x(9) | 

| 36 | SFIDDATE | Virtual File Date stamp, (YYMMDD) | v x(6) | 

| 42 | SFIDTIME | Virtual File Time stamp, (HHMMSS) | v x(6) | 

| 48 | SFIDUSER | User Data | v x(8) | 

| 56 | SFIDDEST | Destination | v x(25) | 
81 SFIDORIG Originator V X(25) 
106 SFIDFMT File Format, (F/V/U/T) F X(1) 

| 107 | SFIDLRECL | Maximum Record Size | v 9(5) | 

| 112 | SFIDFSIZ | File Size, 1K blocks | v 9(7) | 

| 119 | SFIDREST | Restart Position | v 9(9) | 

ii ii o 

SFIDCMD Command Code Character 

Value: 'H” SFID Command identifier. 

SFIDDSN Virtual File Dataset Name String(26) 
Dataset name of the Virtual File being transferred, 
assigned by bilateral agreement. 

No general structure is defined for this attribute. 
See Virtual Files - Identification (Section 1.5.2) 

SFIDRSV1 Reserved String (9) 
This field is reserved for future use. 

SFIDDATE Virtual File Date stamp String (6) 


Format: ‘’YYMMDD’ 6 decimal digits representing the year, month 
and day respectively [ISO-8601]. 


Date stamp assigned by the Virtual File’s Originator 
indicating when the file was made available for 


transmission. 


See Virtual Files - Identification (Section 1.5.2) 
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Format: 


SFIDDEST 


Format: 


SFIDORIG 


Format: 


SFIDFMT 
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Virtual File Time stamp String (6) 


"HHMMSS’ 6 decimal digits representing hours, minutes 
and seconds respectively [ISO-8601]. 


Time stamp assigned by the Virtual File’s Originator 
indicating when the file was made available for 
transmission. 

See Virtual Files - Identification (Section 1.5.2) 

User Data String (8) 
May be used by the ODETTE-FTP in any way. If unused it 
should be initialised to spaces. It is expected that a 
bilateral agreement exists as to the meaning of the data. 
Destination String(25) 
See Identification Code (Section 5.4) 

The Final Recipient of the Virtual File. 

This is the location that will look into the Virtual File 
content and perform mapping functions. It is also the 
location that creates the End to End Response (EERP) 
command for the received file. 

Originator String (25) 
See Identification Code (Section 5.4) 

Originator of the Virtual File. 

It is the location that created (mapped) the data for 
transmission. 

File Format Character 
'F’ Fixed format binary file. 


‘Vv’ Variable format binary file. 
ʻU” Unstructured binary file. 


KTS Text 
Virtual File format. Used to calculate the restart 
position. (Section 1.5.3) 
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SFIDLRECL Maximum Record Size Numeric (5) 
Maximum: 99999 
Length in octets of the longest logical record which may be 
transferred to a location. Only user data is included. 
If SFIDFMT is ’T’ or ’U’ then this attribute must be set to 
00000”. 
SFIDFSIZ File Size Numeric (7) 
Maximum: 9999999 
Space in 1K (1024 octet) blocks required at the Originator 
location to store the Virtual File. 
This parameter is intended to provide only a good estimate 
of the Virtual File size. 
SFIDREST Restart Position Numeric (9) 
Maximum: 999999999 


Virtual File restart position. 


The count represents the: 
- Record Number if SSIDFMT is 'F” or 'V'. 
- File offset in 1K (1024 octet) blocks if SSIDFMT is 
UE Or ET. ¢ 


The count will express the transmitted user data (i.e. 
before compression, header not included). 


After negotiation between adjacent locations, 
retransmission will start at the lowest value. 


5.3.4 SFPA - Start File Positive Answer 


OS ee ee Se Se Se eee O 
SFPA Start File Positive Answer 
| Start File Phase Speaker <---- Listener 
| Pos | Field | Description | Format | 
|----- +----------- AZ +--------—- | 
0 SFPACMD SFPA Command, '2’ F X(1) 
1 SFPAACNT Answer Count V 9(9) 
CO a A a aa a T o 
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Value: 


SFPAACNT 
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Command Code 


r2" SFPA Command identifier. 


Answer Count 


September 1997 


Character 


Numeric (9) 


The Listener must enter a count lower or equal to the 
restart count specified by the Speaker in the Start File 
(SFID) command. The count expresses the received user 
data. If restart facilities are not available, a count of 


zero must be specified. 


5.3.5 SFNA - Start File Negative Answer 


ia ii O 
SFNA Start File Negative Answer 
| Start File Phase Speaker <---- Listener 
| Pos | Field | Description | Format | 
| ----- Ho -- $ +--------- | 
0 SFNACMD SFNA Command, ’ 3’ F X(1) 
1 SFNAREAS Answer Reason F 9(2) 
| 3 | SFNARRTR | Retry Indicator, (Y/N) | E x(1) | 
DO e a e a fe) 
SFNACMD Command Code Character 
Value: ’3’ SFNA Command identifier. 
SFNAREAS Answer Reason Numeric (2) 
Value: “01' Invalid filename. 


Nash 


'02’ Invalid destination. 

‘03’ Invalid origin. 

'04’ Storage record format not supported. 
‘05’ Maximum record length not supported. 
'06’ File size is too big. 

‘10’ Invalid record count. 

‘11’ Invalid byte count. 

'12’ Access method failure. 

‘13’ Duplicate file. 

'99’' Unspecified reason. 


Reason why transmission can not proceed. 
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Retry Indicator Character 


: ‘N’ Transmission should not be retried. 
‘'y’ The transmission may be retried latter. 


This parameter is used to advise the Speaker if it should 
retry at a latter point in time due to a temporary 
condition at the Listener site, such as a lack of storage 
space. It should be used in conjunction with the Answer 
Reason code (SFNAREAS) . 


An invalid file name error code may be the consequence of 
problem in the mapping of the Virtual File on to a real 
file. Such problems cannot always be resolved immediately 


a 


It it therefore recommended that when a SFNA with Retry = Y 
is received the User Monitor attempts to retransmit the 
relevant file in a subsequent session. 
5.3.6 DATA - Data Exchange Buffer 
DEPENDA O SO AS SSeS eee o) 
DATA Data Exchange Buffer 
| Data Transfer Phase Speaker ----> Listener 
| Pos | Field | Description | Format | 
|----- +----------- +-------------------------------------- +--------—- | 
0 DATACMD DATA Command, ’D’ F X(1) 
1 DATABUF Data Exchange Buffer payload V X(n) 
ORS eg ee eee ep ae o) 
DATACMD Command Code Character 
Value: ’D’ DATA Command identifier. 
DATABUF Data Exchange Buffer payload String (n) 
Variable length buffer containing the data payload. The 
Data Exchange Buffer is described in Section 6. 
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5.3.7 CDT = Set Credit 


PEREA a se eae O 
| CDT Set Credit 

| | 
| Data Transfer Phase Speaker <---- Listener 
eee | 
| Pos | Field | Description | Format | 
OS E E A 

O | CDTCMD | CDT Command, 'C* | F X(1) 
| 1 | CDTRSV1 | Reserved | F xX(2) | 
a sean O 
CDTCMD Command Code Character 
Value: ’C’ CDT Command identifier. 
CDTRSV1 Reserved String (2) 
This field is reserved for future use. 

5.3.8 EFID - End File 
OQ O O 
| EFID End File 
| | 
| End File Phase Speaker ----> Listener 

Pos | Field | Description | Format 
|----- +----------- +--------------------------------------- +--------- | 
| 0 | EFIDCMD | EFID Command, 'T' | EX1) | 
| 1 | EFIDRCNT | Record Count |v 9(9) | 
| 10 | EFIDUCNT | Unit Count | v 9(12) | 
in E A RS Oe oma O 
EFIDCMD Command Code Character 


Value: ‘T’ EFID Command identifier. 
EFIDRCNT Record Count 
Maximum: 999999999 


For SSIDFMT 'F” or 'V” the exact record count. 
For SSIDFMT ’U’ or 'T’ zeros. 
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The count will express the real size of the file 
compression, header not included). The total co 
always used, even during restart processing. 
EFIDUCNT Unit Count 
Maximum: 999999999999 


Exact number of units (octets) transmitted. 


tember 1997 


(before 
unt is 


Numeric (12) 


The count will express the real size of the file. The 
total count is always used, even during restart processing. 
.9 EFPA - End File Positive Answer 
O Se ee Sg ee a ee ee ea eee ee ee ro o) 
EFPA End File Positive Answer 
| End File Phase Speaker <---- Listener 
| Pos | Field | Description | Format | 
| ----- +----------—- +------------------------------------- +--------- | 
0 EFPACMD EFPA Command, ’ 4’ F X(1) 
1 EFPACD Change Direction Indicator, (Y/N) F X(1) 
ORTA O NO O O O O o) 
EFPACMD Command Code Character 
Value: '4” EFPA Command identifier. 
EFPACD Change Direction Indicator Character 
Value: ’N’ Change direction not requested. 
“Y” Change direction requested. 
This parameter allows the Listener to request a Change 
Direction (CD) command from the Speaker. 
5.3.10 EFNA - End File Negative Answer 
ORS SS ee ee ee o 
EFNA End File Negative Answer 
| End File Phase Speaker <---- Listener 
| Pos | Field | Description | Format | 
|----- +----------—- +------------------------------------- +--------- | 
0 EFNACMD EFNA Command, ’5’ F X(1) 
1 EFNAREAS Answer Reason F 9(2) 
e a ee Se ae ee Ha ee eee o) 
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Value: 


EFNAREAS 
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Command Code Character 
Or EFNA Command identifier. 
Answer Reason Numeric (2) 


‘01’ Invalid filename. 

'02’ Invalid destination. 

‘03’ Invalid origin. 

'04’ Storage record format not supported. 
‘05’ Maximum record length not supported. 
'06’ File size is too big. 

‘10’ Invalid record count. 

‘11’ Invalid byte count. 

'12’ Access method failure. 

‘13’ Duplicate file. 

'99’' Unspecified reason. 


Reason why transmission can not proceed. 


5.3.11 ESID - End Session 


partons 
| 
| 
| 
| fa caer a 
Pos | 
ES +- 
| o] 
| a4 
[3] 
gatEziis 
ESIDCMD 
Value: 
ESIDREAS 
Value 
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EPA O e A A ee eee o 
ESID End Session 
End Session Phase Speaker ----> Listener 
Field | Description | Format 
aa Ss A a ii 
ESIDCMD | ESID Command, 'F’ | F X(1) | 
ESIDREAS | Reason Code | F 9(2) | 
ESIDCR | Carriage Return | F X(1) | 
he enn E ee EI e A a A E PRE ER en a o 
Command Code Character 
'F’ ESID Command identifier. 
Reason Code Numeric (2) 
‘00’ Normal session termination 
‘01’ Command not recognised 
An Exchange Buffer contains an invalid command code 
(lst octet of the buffer). 
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Protocol violation 


An Exchange Buffer contains an invalid command for 
the current state of the receiver. 


User code not known 


A Start Session (SSID) command contains an unknown or 
invalid Identification Code. 


Invalid password 


A Start Session (SSID) command contained an invalid 
password. 


Local site emergency close down 


The local site has entered an emergency close down 
mode. Communications are being forcibly terminated. 


Command contained invalid data 


A field within a Command Exchange buffer contains 
invalid data. 


Exchange Buffer size error 


The length of the Exchange Buffer as determined by 
the Stream Transmission Header is different to the 
length implied by the Command Code. 


Resources not available 
The request for connection has been denied due to a 


resource shortage. The connection attempt should be 
retried later. 


Time out 
Mode or capabilities incompatible 
Unspecified Abort code 


An error was detected for which no specific code is 
defined. 
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ESIDCR Carriage Return Character 
Value: Character with hex value ’0D’ or ’8D’. 


5.3.12 CD - Change Direction 


E O 
| CD Change Direction 

Start File Phase Speaker ----> Listener 
| End File Phase Speaker ----> Listener 
| End Session Phase Initiator <---> Responder 
| Pos | Field | Description | Format | 
|----- +----------—- AO +--------- | 
| 0 | CDCMD | CD Command, ’R’ | F X(1) | 
DATA a ATAR O 
CDCMD Command Code Character 


Value: ’R’ CD Command identifier. 


5.3.13 EERP - End to End Response 


QR SSSR PSs ese eae SS Ste Se eS Pee S eee a aS eS SS ee cee eases o 
| EERP End to End Response 
| 
Start File Phase Speaker ----> Listener 

| End File Phase Speaker ----> Listener 
ee eee ee O ee ee Oe eee 
| Pos | Field | Description | Format | 
|----- +----------—- $ +--------- | 
| 0 | EERPCMD | EERP Command, 'E' | F x(1)_ | 

1 | EERPDSN Virtual File Dataset Name V X(26) | 
| 27 | EERPRSV1 Reserved F X(9) 
| 36 | EERPDATE | Virtual File Date stamp, (YYMMDD) | v x(6) | 
| 42 | EERPTIME | Virtual File Time stamp, (HHMMSS) | v x(6) | 
| 48 | EERPUSER | User Data | v x(8) | 
| 56 | EERPDEST | Destination | v x(25) | 
| 81 | EERPORIG | Originator | V x(25) 
A ag pg ey OP aca feet SEW AT ST fa, a EWG Tee ETT A AG TS tT VE Wg AN AIR Toe Oo 
EERPCMD Command Code Character 


Value: 'E' EERP Command identifier. 
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EERPTIME 


Format: 


EERPUSER 


EERPDEST 
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Virtual File Dataset Name String (26) 


Dataset name of the Virtual File being transferred, 
assigned by bilateral agreement. 


No general structure is defined for this attribute. 
See Virtual Files - Identification (Section 1.5.2) 


Reserved String (9) 
This field is reserved for future use. 
Virtual File Date stamp String (6) 


"YYMMDD’ 6 decimal digits representing the year, month 
and day respectively [ISO-8601]. 


Date stamp assigned by the Virtual File’s Originator 
indicating when the file was made available for 
transmission. 

See Virtual Files - Identification (Section 1.5.2) 


Virtual File Time stamp String (6) 


"HHMMSS’ 6 decimal digits representing hours, minutes 
and seconds respectively [IS0-8601]. 


Time stamp assigned by the Virtual File’s Originator 
indicating when the file was made available for 
transmission. 

See Virtual Files - Identification (Section 1.5.2) 

User Data String (8) 
May be used by the ODETTE-FTP in any way. If unused it 
should be initialised to spaces. It is expected that a 
bilateral agreement exists as to the meaning of the data. 
Destination String (25) 
See Identification Code (Section 5.4) 


Originator of the Virtual File. 


This is the location that created (mapped) the data for 
transmission. 
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EERPORIG Originator String (25) 
Format: See Identification Code (Section 5.4) 
Final Recipient of the Virtual File. 
This is the location that will look into the Virtual File 
content and perform mapping functions. It is also the 


location that creates the EERP for the received file. 


5.3.14 RTR - Ready To Receive 


OR SSS O A RR AN ARA ARA AAA AS ARS AAA o 
| RTR Ready To Receive 
| Start File Phase Initiator <---- Responder 

End File Phase Initiator <---- Responder 
| Pos | Field | Description | Format | 
|----- Ho $ +--------—- | 
| 0 | RTRCMD | RTR Command, 'P” | E X(1) | 
e E a o 
RTRCMD Command Code Character 


Value: ‘’P’ RTR Command identifier. 
5.4 Identification Code 


The Initiator (sender) and Responder (receiver) participating in an 
ODETTE-FTP session are uniquely identified by an Identification Code 
based on [ISO 6523], Structure for the Identification of 
Organisations (SIO). The locations are considered to be adjacent for 
the duration of the transmission. 


The SIO has the following format. 


Osa? A SSS SSS SS aS a SSS eee SaaS ae Se aaassa o 
| Pos | Field | Description | Format | 
|----- +----------- +------------------------------------- +--------- | 
| 0 | SIOOID ODETTE Identifier F X(1) | 
1 SIOICD International Code Designator V 9(4) 
| 5 | SIOORG | Organisation Code | v x(14) | 
| 19 | SIOCSA | Computer Sub-Address | v x(6) | 
a a ae et eee o 
SIOOID ODETTE Identifier Character 


Value: ’0’ Indicates ODETTE assigned Organisation Identifier. 
Other values may be used for non-ODETTE codes. 
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6. 


6. 


6. 


SIOICD International Code Designator String (4) 


A code forming part of the Organisation Identifier. 


SIOORG Organisation Code String (14) 


A code forming part of the Organisation Identifier. This 


field may contain the letters A to Z, the digits 0 to 9, 
apace and hyphen characters. 


SIOCSA Computer Sub-Address String (6) 


A locally assigned address which uniquely identifies a 


system within an organisation (defined by an Organisation 


Identifier). 
ODETTE-FTP Data Exchange Buffer 
1 Overview 


Virtual Files are transmitted by mapping the Virtual File records 
into Data Exchange Buffers, the maximum length of which was 
negotiated between the ODETTE-FTP entities via the Start Session 
(SSID) commands exchanged during the Start Session Phase of the 
protocol. The format is based on the Network Independent File 
Transfer Protocol [NIFTP]. 


Virtual File records may be of arbitrary length. A simple 
compression scheme is defined for strings of repeated characters. 


An example of the use of the Data Exchange Buffer can be found in 
Appendix A. 


2 Data Exchange Buffer Format 
For transmission of Virtual File records, data is divided into 


Subrecords, each of which is preceded by a one octet Subrecord 
Header. 


The Data Exchange Buffer is made up of the initial Command character, 
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CMD 
The Data Exchange Buffer Command Character, 'D'. 
HDR 


A one octet Subrecord Header defined as follows: 


DA a a T Oaa TE o 
Ejec] | 
fiero ann fe ia (lee NT | 
[R| | | 
Qn a a E o 
Bits 
0 End of Record Flag 


Set to indicate that the next subrecord is the last 
subrecord of the current record. 


Unstructured files are transmitted as a single record, in 
this Case the flag acts as an end of file marker. 


1 Compression Flag 
Set to indicate that the next subrecord is compressed. 
2-7 Subrecord Count 


The number of octets in the Virtual File represented by the 
next subrecord expressed as a binary value. 


For uncompressed data this is simply the length of the 
subrecord. 


For compressed data this is the number of times that the 
single octet in the following subrecord must be inserted in 


the Virtual File. 


As six bits are available, the next subrecord may 
represent between 0 and 63 octets of the Virtual File. 


6.3 Buffer Filling Rules 


An Exchange Buffer may be any length up to the value negotiated in 
the Start Session exchange. 
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Virtual File records may be concatenated within one Exchange Buffer 
or split across a number of buffers. 


A subrecord is never split between two Exchange Buffers. If the 
remaining space in the current Exchange Buffer is insufficient to 
contain the next ’complete’ subrecord one of the following strategies 
should be used: 


1. Truncate the Exchange Buffer, and put the complete 
subrecord (preceded by its header octet) in a new Exchange Buffer. 


2. Split the subrecord into two, filling the remainder of the 
Exchange Buffer with the first new subrecord and starting a new 
Exchange Buffer with the second. 


A record of length zero may appear anywhere in the Exchange Buffer. 


A subrecord of length zero may appear anywhere in the record and/or 
the Exchange Buffer. 


7. Stream Transmission Buffer (TCP only) 
7.1 Introduction 


The ODETTE-FTP was originally designed to utilise the ISO Network 
Service, specifically the X.25 specification. It relies on the fact 
that the network service will preserve the sequence and boundaries of 
data units transmitted through the network and that the network 
service will pass the length of the data unit to the receiving 
ODETTE-FTP. The TCP offers a stream based connection which does not 
provide these functions. 


In order to utilise the TCP stream without disruption to the existing 
ODETTE-FTP a Stream Transmission Buffer (STB) is created by adding a 

Stream Transmission Header (STH) to the start of all Command and Data 
Exchange Buffers before they are passed to the TCP transport service. 
This allows the receiving ODETTE-FTP to recover the original Exchange 
Buffers. 


STH - Stream Transmission Header 
OEB - ODETTE-FTP Exchange Buffer 


The Stream Transmission Buffer comprises of a STH and OEB. 
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7.2 Stream Transmission Header Format 


The Stream Transmission Header is shown below. The fields are 
transmitted from left to right. 


0 1 2 3 
012345678901234567890123456789021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Version| Flags | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Version 
Value: 0001 (binary) 
Stream Transmission Header version number. 
Flags 
Value: 0000 (binary) 
Reserved for future use. 
Length 
Range: 5 - 100003 (decimal) 
The length of the Stream Transmission Buffer (STH+OEB). 
The smallest STB is 5 octets consisting of a 4 octet header 
followed by a 1 octet Exchange Buffer such as a Change Direction 


(CD) command. 


The maximum Exchange Buffer length that can be negotiated is 99999 
octets (Section 5.3.2) giving a STB length of 100003. 


The length is expressed as a binary number with the most 
significant bit on the left. 


It is expected that implementations of this protocol will follow the 


Internet robustness principle of being conservative in what is sent 
and liberal in what is accepted. 
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8. Protocol State Machine 
8.1 ODETTE-FTP State Machine 


The operation of an ODETTE-FTP entity is formally defined by the 
State Machine presented below. There are five State and Transition 
tables and for each table additional information is given in the 
associated Predicate and Action lists. 


The response of an ODETTE-FTP entity to the receipt of an event is 
defined by a Transition table entry indexed by the Event/State 
intersection within the appropriate State table. 


Each Transition table entry defines the actions taken, events 
generated and new state entered. Predicates may be used within a 
table entry to select the correct response on the basis of local 
information held by the entity. 


A transition table contains the following fields: 
Index (T) State transition index. 
Predicate A list of predicates used to select between different 


possible transitions. The predicates are defined in the 
Predicate and Action list. 


Actions A list of actions taken by the entity. The actions are 
defined in the Predicate and Action list. 


Events Output events generated by the entity 
Next State The new state of the entity. 
8.2 Error Handling 


The receipt of an event in a given state may be invalid for three 


reasons. 
1. The case is impossible by construction of the state automata, 
denoted 'X” in the State tables. For example a timer which has 


not been set cannot run out. 


2. The event is the result of an error in the Network Service 
implementation, also denoted ’X’ in the state tables. The 
Network Service implementation is considered to be correct. 


3. For all other cases the event is considered to be a User Error, 
denoted "U" in the state tables. 
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The State tables define the conditions under which a User event is 


valid, thus preventing the generation of a protocol error by the 
ODETTE-FTP entity as a result of a User Monitor error. The reaction 
of the entity to such errors is undefined and regarded as a local 
implementation issue. 


The State tables also allow protocol errors due to the receipt of 
invalid Exchange Buffers, to be detected. In such cases the reaction 
of the entity to the error is defined. 


8.3 States 


The Command Mode is strictly a Half Duplex Flip-Flop Mode. 


A_NC_ONLY 


A_WF_CONRS 


CDSTWFCD 


CLIP 


CLOP 


ERSTWFCD 


Nash 


Responder, Network Connection opened 


The Responder has sent it’s Ready Message (SSRM) and is 
waiting for Start Session (SSID) from the Initiator. 


Responder Waiting for F_CONNECT_RS 

The Responder has received the Initiator’s Start Session 
(SSID) and is waiting for a response (F_CONNECT_RS) from 
it’s User Monitor. 

CD_RO stored in WF_CD state 

Since the User Monitor doesn’t see the WF_CD state it may 
send a Change Direction request (F_CD_RQ) before the 
ODETTE-FTP receives a Change Direction (CD) command. 
Close Input Pending 

The Listener has received an End File (EFID) command and 


is waiting for the Close File response (F_CLOSE_FILE_RS) 
from it’s User Monitor. 


Close Out Pending 


The Speaker has sent an End File (EFID) command and is 
waiting for an End File Answer (EFPA or EFNA). 


End to End Response stored in WF_CD state 
Since the User Monitor doesn’t see the WF_CD state it may 


send F_EERP_RO, before the ODETTE-FTP receives a Change 
Direction (CD) command. 
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I_WF_NC 


I_WF_RM 


I_WF_SSID 


OPI 
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Connection IDLE 

Idle Listener 

Idle Listener, F_CD_RQ Received 

The ODETTE-FTP entity has become the Listener after 
receiving a Change Direction request (F_CD_RQ) from the 
User Monitor. The receipt of an End Session (ESID) is 
valid in this state. 

Idle Speaker 

Idle Speaker, F_CD_IND Sent 

The ODETTE-FTP entity has sent a Change Direction 
indication (F_CD_IND) to the User Monitor. A Change 
Direction request (F_CD_RQ) is invalid in this state. 
Initiator Waiting for Network Connection 

The Initiator has requested a new network connection and 
is waiting for a Connection confirmation (N_CON_CF) from 
the Network Service. 


Initiator Waiting for Ready Message 


Before sending Start Session (SSID), the Initiator must 
wait for a Ready Message (SSRM) from the Responder. 


Initiator Waiting for SSID 


The Initiator has sent a Start Session (SSID) command and 
is waiting for Start Session from the Responder. 


Open Input (Data Transfer Phase) 


The Listener is waiting for the Speaker to send a Data 
Exchange buffer. 


Open Input Pending 
The Listener has received a Start File (SFID) command and 


is waiting for the Start File response (F_START_FILE_RS) 
from it’s User Monitor. 
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Open Out (Data Transfer Phase) 

The Speaker has received a Start File Positive Answer 
(SFPA) and is waiting for a Data (F_DATA_RQ) or Close 
File (F_CLOSE_FILE) request from it’s User Monitor. 
Open Out Pending 


The Speaker has sent a Start File (SFID) command and is 
waiting for a Start File Answer (SFPA or SFNA). 


Open Out Wait for Credit 


The Speaker is waiting for a Set Credit (CDT) command 
before sending further Data Exchange buffers. 


Start File Request stored in WF_CD state. 
Since the User Monitor doesn’t see the WF_CD state it may 


send a Start File request (F_START_FILE_RQ) before the 
ODETTE-FTP receives a Change Direction (CD) command. 


Wait for Change Direction 


The Listener wishes to become the Speaker and is waiting 
for a Change Direction (CD) command after sending an End 
File Positive Answer (EFPA) requesting change direction. 


Wait for Ready To Receive 

The Initiator has sent an End to End Response (EERP) 
command and must wait for Ready To Receive (RTR) from the 
Responder. 

Wait for N_DISC_IND 

ODETTE-FTP has sent an End Session (ESID) command and is 


waiting for a Disconnection indication (N_DISC_IND) from 
the Network Service. 


8.4 Input Events 


User Monitor Input Events (Section 3) 


F_DATA_RO 
F_EERP_RO 
F_CD_RO 


Nash 


F_CONNECT_RO F_START_FILE_RO F_CLOSE_FILE_RO 
F_CONNECT_RS F_START_FILE_RS (+) F_CLOSE_FILE_RS (+) 
F_ABORT_RO F_START_FILE_RS(-) F_CLOSE_FILE_RS(-) 
F_RELEASE_RO 
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Network Input Events (Section 2.2) 
N_CON_IND N_CON_CF N_DATA_IND N_DISC_IND N_RST_IND 
Peer ODETTE-FTP Input Events (Section 4) 


SSID SFID SFPA SFNA EFID EFPA EFNA 
DATA ESID EERP RTR CD CDT SSRM 


Internal Input Events 

TIME-OUT - Internal ODETTE-FTP timer expires. 
Input event parameters are denoted I.Event-name.Parameter-name within 
the state table action and predicate lists. Their value can be 
examined but not changed by the ODETTE-FTP entity. 


8.5 Output Events 


User Monitor Output Events (Section 3) 


F_DATA_ IND F_CONNECT_IND F_START_FILE_IND F_CLOSE_FILE_IND 
F_EERP_IND F_CONNECT_CF F_START_FILE_CF (+) F_CLOSE_FILE_CF (+) 
F_CD_IND F_ABORT_IND F_START_FILE_CF (-) F_CLOSE_FILE_CF (-) 


F_RELEASE_IND 
Network Output Events (Section 2.2) 
N_CON_RQ N_CON_RS N_DATA_RO N_DISC_RO 
Peer ODETTE-FTP Output Events (Section 4) 


SSID SFID SFPA SFNA EFID EFPA EFNA 
DATA ESID EERP RTR CD CDT SSRM 


Output event parameters are denoted O.Event-name.Parameter-name 
within the state table action and predicate lists. Their values can 
be examined and changed by the ODETTE-FTP entity. 
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8.6 Local Variables 


The following variables are maintained by the ODETTE-FTP entity to 
assist the operation of the protocol. They are denoted V.Variable- 
name within the state table action and predicate lists. Their value 
can be examined and changed by the ODETTE-FTP entity. The initial 
value of each variable is undefined. 


Variable Type 


Buf-size Integer 
Called-addr Address 
Calling-addr Address 
Compression Yes/No 


Credit_L Integer 
Credit_S Integer 
Id String 
Mode 

Pswd String 
Reg-buf Primitive 
Restart Yes/No 
Restart-pos Integer 
Window Integer 


8.7 Local Constants 


Negotiated Exchange Buffer size. 

Used to build O.F_CONNECT_IND.Called-addr 
To build O.F_CONNECT_IND.Calling-addr 
Compression in used as agreed. 

Listeners credit counter. 

Speaker's credit counter. 

Used to build O.SSID.Id 

Sender-only, Receiver-only, Both. 

Password, used to build O.SSID.Pswd 

Input event (F_XXX_RQ) stored in WF_CD state. 
Restart in used as agreed. 

Used only during file opening. 

The Credit value negotiated for the session. 


The following constants define the capabilities of a given ODETTE-FTP 
entity. They are denoted C.Constant-name within the state table 
action and predicate lists. Their value can be examined but not 
changed by the ODETTE-FTP entity. 


Constant Value 


Cap-compression Yes/No 


Comments 


Compression supported? 


Cap-init Initiator Must be Initiator. 

Responder Must be Responder. 

Both Can be Initiator or Responder. 
Cap-mode Sender-only Must be sender. 

Receiver-only Must be receiver. 

Both Can be sender or receiver. 
Max-buf-size 127 < Int < 100000 Maximum buffer size supported. 
Max-window Int < 1000 Local maximum credit value. 
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8.8.2 Transition Table 


I | Predicate Actions Output Events Next State 
e) 
A | Pl: F_ABORT_IND IDLE 
| not Pl: 1 N_CON_RO I_WF_NC 
=-=-—+ A EE ee he ee A ee se ee A A o A o A E ee NES 
B | P3: N_DISC_RO IDLE 
not P3: N_CON_RS 
SSRM A_NC_ONLY 
==-—+ RAS SA A A SAS A A AS A A A E A A A SA NA A A AS AU 
c| 2 I_WF_RM 
---+ A AAA AA AAA A A ey i A A A A A O ees re es gy ee es ae a gs ieee A aps ee et 
D | P2: 4,2,5 F_CONNECT_CF IDLESP 
| not P2: 4,2 ESID (R=10) 
| F_ABORT_IND (R, AO=L) WF_NDISC 
---+ A A ee Ad a la A o tt gb oi e il A e fs a hs ee ah lb aes a ad a eet ep Pd 
E | P4: 4 N_DISC_RO IDLE 
| not P4: F_CONNECT_IND A_WF_CONRS 
=-=-—+ E A A A A EEE NS 
F | F_ABORT_IND 
| N_DISC_RO IDLE 
==—+ A A A A A o A e ee a a a A a 
G | P2: Ay SSID IDLELI 
| not P2: 4,2 ESID (R=10) 
| F_ABORT_IND (R, AO=L) WF_NDISC 
---+ ye A A A A A A ee ay Sy a ny nC ape EN 
H | 4,2,3 SSID I_WF_SSID 
8.8.3 Predicates and Actions. 
Predicate Pl: (No resources available) OR 


(C.Cap-init = Responder) OR 

(C.Cap-mode = Sender-only AND 
T.F_CONNECT_RO.Mode = Receiver-only) OR 

(C.Cap-mode = Receiver-only AND 
I.F_CONNECT_RO.Mode = Sender-only) 


Predicate P2: Negotiation of (Buf-size, Restart, Compression, 
Mode, Credit) is OK. 


Predicate P3: C.Cap-init = Initiator 


Predicate P4: Mode in SSID incompatible with C.Cap-mode 
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Set V.Mode from (C.Cap-mode, I.F_CONNECT_RQ.Mode) 
Set V.Pswd, V.Id, V.Restart from I.F_CONNECT_RQ 


Set V.Buf-size = C.Max-buf-size 

Set V.Compression = C.Cap-compression 
Build O.N_CON_RO 

Start inactivity timer 

Set parameters in O.SSID = from local 


Stop timer 


Set V.Mode, V.Restart, V.Compression, 
V.Window = from SSID 


8.9 Error and Abort State Table 


8.9.1 State Table 


Oe SSS SS as o 
| | Other States | 
ÓN ES sa Ssssse o 
| T | WF_NDISC | | 
| a | o | | 
| T | 1_WF_NC | | | 
| E | o | | | 
| | IDLE ee allt! sl 
o---+---+---+--- 
| | TIME-OUT RRIA B | 
| |------------------ +---+---+---+-—- | 
| E | F_ABORT_RO HL ME 
| v |------------------ +---+---+---+-—- | 
| E | N_RST_IND Digan in Al. «B| 
N | ------------------ 4+---+---+---4+--- 
| E | N_DISC_IND Ix] E]|E]G | 
| | ------------------ +---+4---+4---+4--- | 
| | Invalid Buffer | X | X | H | I | 
C a SOS Sane css oases o 
Nash Informational 
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8.9.2 Transition Table 


I | Predicate Actions Output Events Next State 
Oo 
A | N_DISC_RO IDLE 
==-—+ A A A a e E et a a es at ed A e Pl he em e Js ds ad a a A A yt lr a e ad 
B | F_ABORT_IND 
| N_DISC_RQ IDLE 
=-=-—+ E A AT A A A A A A SS Ss St A A 
Cer 1 N_DISC_RQ IDLE 
---+ SSS SS SS O SS SS AA A SSeS SS SS SSS SS eS ee Se Se Sa 
D | 1 N_DISC_RO 
| F_ABORT_IND IDLE 
---+ A A A A ee Se See A A e Se Se ee PS a Se ee 
E | F_ABORT_IND IDLE 
=-=-—+ A AA A A A A A ee Se A A A A o A fee A A 
F | 1 IDLE 
---+ I Sa a a ji ms Re a E Ey lt as A o E o A o A a at ae gl el Ry at AA ed 
G | 1 F_ABORT_IND IDLE 
---+ PERE cc ap a EE E ae A A a al tS pl eel ey na act O mate tee at a E a rd aah 
H | WF_NDISC 
=-=-—+ E A A SSS SO o A SS o A O a eS ee SS o A O Se E o A A A AS 
Tl 1,2 ESID (R=01) 
| F_ABORT_IND (R, AO=L) WF_NDISC 


8.9.3 Predicates and Actions. 
Action 1: Stop inactivity timer 
Action 2: Start inactivity timer 
8.10 Speaker State Table 1 
8.10.1 State Table 
The following abbreviations are used in the Speaker State table. 


F_REL_RQ (Ok) —- F_RELEASE_RQ Reason = Normal 
F_REL_RO(Err) -= F_RELEASE_RO Reason = Error 
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A A A A A A A eS eS ey O 
| | | | | | | | | | l 
! =] ! D | ¡0) ! oO ! O | D | vo | D ! D ! Q E 
— A U a a ote il 
| Ee Se ie etn AO 
er ee ae a oe ob a a 
i ol see ae career ee ee al 
AA folie te peer dere leon Pax dee seas DNA 
ai al ease sar ac acs cs ae a ae aa 
i qe: At a ee Ta oo ah rl eee eat ok 
iy as A A Ske sya eee 
bh. ug ee Say we Plies a Bc Set oka ie eg 
Pik a) a ee ee al Mol Raid Lorie all ce 
Be Hos Rig, Th, E ee et Ls tb ay he A cat do 
i We a ane. a pub ea ee cee ea ee ate 
dhe Mee aut a aa e ie a tee ochre E bn: 
Pe EP sk! Se a E A see ae a a ee a 
| | | | | | | 0 —— a + — + — + — 4H — 4H — 4H — 4H — YH 4H —+— 
| | | | | | | ] | | | | | | | | | | l 
Le He, ¡del ai ea fe ca pc a eee eat 
| | | | | | | | o— + — + —— + —+ — + —+ —+ — + — + —+ —+— 
| | | | | | | | ] | | | | | | | | | | | 
A ae aie ae dn aie Bie ee See AO 
| | | | | | | | | (0) + — + — + —4+—4+—4+—4+—4+—4+—4+—4+— 
l | | l | l | | | ] | | | | | | | | | | | 
es oa HS a a et ee ea 
| | | | | | | l l | o — + — + — + — + — + — + — +t —+—+ — + — KH 
| | | | | | | | | | ] | | | | | | | | | | | 
| | | | | | | | | | | 1 gia ¡ESA SE SE BLO kA yh Ob Te. 
| | | | | | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | o — + —— + — + — + — + — + — + — + — + —+— 
| | | | | | | | | | | | | | | | | | | Lal 
| l | | | | | | | | | | | | | | | | Ilali 4 
v | | | | | | | | | | | | | | | | | | Ix toy 
pl | | | | | | | | | | | | | | | | | 1olwl 
oO | | | | | | | | | | | Q | Oe! | | 1 Ql | IES 1] 
plot | | VAJTA AA | Lal IS a R | | 11 | 1ralriat 
nin | | | i Ya IN B| | oe | lIi ee Jl | | be If sl 1oa;na smal 
lH IO I | lm! & | & I NN ww! | | 1 gil (fas = Wee Fame oe al 
91011 | IZ IZIZIQAIHININQN G I gH il | | LEI A E 
012131 lotrel HItHI OIMIA! wa BlHH Il gl gl | IO IHIIHI 
Gal O AO O 10 LEE Oe the as a lnm | al eZ il 1|1Ql1B101A1Al1A 
PlH!laiaIiogo!l! atlmw!t@Iuwlan!tiata paro] lfijlkatlato)1ato]1o0J]1o0J]10 
(e) zZ l (@) l (o) l (@) | 9) wn l El = = H ! H iu l fy ! n ! 19) oO fy O fy fy l fy l aa 
O O + O A 
n E 54 E E E > E Z E 
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8.10.2 Transition Table 


I | Predicate Actions Output Events Next State 
O 
A | 1,2,3 EERP WE_RTR 
=-=-—+ A a e Js ad e y re ie do o y e emp nh ad el y O dr A la e a pd el y o a il ol yl a e a a il yl ed joo e E da 
B | Pl UE 
| not P1 Lop SFID OPOP 
---+ E Naw A a a a eh ee ee a te 
om 12 ESID (R=02) 
| F_ABORT_IND (R, AO=L) WF_NDISC 
——-+ ny ny ay a O A A ee a A A A A A A A AE 
D | 1,2 CD IDLELICD 
=-=-—+ Se AS A AAA AA AA A e AA A A A A A A A A AA E 
E | 1,2 ESID (R=00) WF_NDISC 
---+ See Se O A eae A A oe Se ee ee a ee a 
F | 4 ERSTWFCD 
=-=-—+ a a a e A O ee ee a A O ee ee A ee A A 
G | Pl: UE 
| not P1 6 SFSTWFCD 
=-=—+ A A A Sn A A A A A A ee ie 
H | 1,2 IDLESP 
---+ AAA A A A AA A a ae eg ay ey Se Oey ae ee 
T. 1,2,10 SFID OPOP 
==—+ A AAA AAA A A AAA AA A AAA A E A A O ii a See 
J | 1422, CD IDLELICD 
=-=-—+ O A A NE E O A A A EN 
K | P2: 1,2 ESID (R=02) 
F_ABORT_IND (R, AO=L) WF_NDISC 
| not P2: 12112 F_START_FILE_CF (+) OPO 
---+ a A A ii A A a eS EE EEE a pt a A A A 
Tal 1,2,8 F_START_FILE_CF (-) IDLESP 
---+ AD ee ee ee Se ee ee le Le Se es ee ee oe Se a ee o 
M | P3: 1,2,11,13 DATA OPOWFC 
not P3: 1,2,11,13 DATA OPO 
---+ Se SS AA AAA A A AA AA A A A A A See A A eee ee 
N | Note 3 IDLESP 
---+ aS ee Se Se ee ee Se ee Se ee oa a ee eee ee ee 
o | 12 OPO 
| See Note 1 
——-+ A A A e E i A PA e a A e a a ji al ES a ai a e rd ad peas e e e a pi ia el met et ee Sale se k 
P | Protocol eer ESID (R=02) 
| Error F_ABORT_IND (R, AO=L) WF_NDISC 
---+ SSS SS SS ee eS SS Se Se SS a Se eS a a ee ee ee ee ee a AS 
Q | 1,2 ESID (R) WF_NDISC 
==-—+ Ej A AN A TN a a a o A A ii A eh te ip ml ey ee el tl e cl apd aah ee 


Continued --> 
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I | Predicate Actions Output Events Next State 
o 
R | 1,2,9 EERP WF_RTR 
——-+ Fe a EE E AAA E E E AA AAA AA AA AR AA AI A 
s | WF_NDISC 
---+ Sac Sd AN me Sat Sree es Sm Sl RES RN RAN TAE IN Se St, AAN A PA pep aes E ge AA AMA 
T., CDSTWFCD 
=-=-—+ PAE E A A E A EA A AA AA SRA AA SAA AAA 
U | User Error UE 
==-—+ TA A A E A A AE A E E ER A E E 
V | User Error - Note 1 UE 
—---+ E EP A A A A A E ES E O A ae oe O NN 
W | User Error - Note 2 UE 
=-=-—+ PAE E E E AR E EA EA A E E AE A EA E ERA 
x | Error 


8.10.3 Predicates and Actions. 


Predicate Pl: (I.F_START_FILE_RQ.Restart-pos > 0) AND 
((V.Restart = No) OR (V.Mode = Receiver-only) ) 


Note: Restart requested and not supported for this session. 
Predicate P2: (I.SFPA.Restart-pos > V.Restart-pos) 
Note: Protocol error due to the restart position in the 
SFPA acknowledgement being greater than the position 


requested in the SFID request. 


Predicate P3: V.Credit_S - 1 = 0 


Note: Speaker’s Credit is exhausted. 
Action 1: Stop inactivity timer 
Action 2: Start inactivity timer 


Action 3: Build an EERP from F_EERP_RO 
Action 4: Store F_EERP_RO in V.Req-buf 


Action 5: Build SFID from F_START_FILE_RO 
V.Restart-pos = I.F_START_FILE_RQ.Restart-—pos 


Action 6: Store F_START_FILE_RO in V.Req-buf 


Action 7: Build F_START_FILE_CF(+) from I.SFPA 
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Action 8: Build F_START_FILE_CF(-) from I.SFNA 
Action 9: Build EERP from F_EERP_RO stored in V.Req-buf 
Action 10: Build SFID from F_START_FILE_ROQ stored in V.Req-buf 
Set V.Restart-pos 
Action 11: Build Exchange Buffer 
Action 12: V.Credit_S = V.Window 
Action 13: V.Credit_S = V.Credit_S - 1 

Note 1: The OPOWFC state prevents the Speaker from sending 
data buffers because it is waiting for credit. The 
ODETTE-FTP entity may need to control the flow of Data 
requests (F_DATA_RQ) from it’s User Monitor to protect 
it’s own buffers. Any such mechanism and the 
behaviour of the entity should a User Error occur are 
regarded as local implementation issues. 

Note 2: The choice to accept this "Request/Event" while in 
this state is a matter of local implementation. The 
ODETTE state tables are based on the assumption that 
this event cannot occur in this state and is 
considered to be a user error (UE). 

Note 3: It is a local matter to make the User Monitor aware 
that since the RTR is received, the protocol machine 
is now ready to accept the next request. 

8.11 Speaker State Table 2 
8.11.1 State Table 
On a n a O 
| s | CLOP | 
| T | o | 
| A | OPOWFC | | 
To n S sess serSes O 
E | OPO | 
| PE EEEE 
| E | F_CLOSE_FILE_RQ | A | E | U | 
[q | Sees actes pepe pito | 
| E | EFPA l-Beni 
N |----------------- +---+---+--- 
T | EFNA |BİBİD 
OETA EN Se a ae o) 
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8.11.2 Transition Table 


I | Predicate Actions Output Events Next State 
o 
A | 1,2,5,7 EFID CLOP 
==-—+ E  _  _ _ _  _ — _ ___ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  _ _ _ _ _ __ nv 
B | le ESID (R=02) 
| F_ABORT_IND (R, AO=L) WF_NDISC 
---+ =-= — A _ A  __ __—__——_— —_ _ _  _ _ _  _ _ _ _ _ _ _ _ _ _ ____——_—————————— —— ——— 
c | Pl: 1,2,3 F_CLOSE_FILE_CF (+, SP=No) 
| CD IDLELI 
| not P1: 1,2,4 F_CLOSE_FILE_CF (+, SP=Yes) IDLESP 
---+ _ A — — — _  _ _ _ _ _ _ _ _ _— _  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ cnn 
D | 1,2,6 F_CLOSE_FILE_CF (-) IDLESP 
---+ =-= — — >= -—_—_—_— _  _ __ _ _ _ _ _  _ _ _ _ _ _ _ _ _ __ __—_——_———c— cc —————————— —— —— —— 
E | See Note 1 
---+ ——— — — _ _ —_  _ _ _  ____ _ _ __ _ _ _  _  __ _ _ _ __ _ _ _ __ even o 
U | User Error UE 


8.11.3 Predicates and Actions. 


Predicate Pl: (I.EFPA.CD-Request = Yes) AND (V.Mode = Both) 


Action 1: Stop inactivity timer 
Action 2: Start inactivity timer 
Action 3: O.F_CLOSE_FILE_CF(+).Speaker = No 
Action 4: O.F_CLOSE_FILE_CF (+) .Speaker = Yes 


Action 5: Build EFID from F_CLOSE_FILE_RO 


Action 6: Build F_CLOSE_FILE_CF(-) from EFNA 


Action 7: Set V.Credit_S = 0 


Note 1: In order to respect the "half duplex" property of 
ODETTE-FTP it is forbidden to send EFID while in the 
OPOWFC state. EFID can be sent only in the OPO state. 


The ODETTE-FTP implementation must avoid sending EFID 
(or receiving F_CLOSE_FILE_RQ) while in the OPOWFC 
state. 
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Listener State Table 


EZ 


State Table 


8.12.1 


| | | | | | | | | 
m l m ! m l D | NÓ ! M ! A l Q | m 
A A e o ck Op I ae 
| ee ek eee 
ie fps 2 i ie ld Sel te ee, lc 
Pt aah a ae eal ee ak ce atk 
Pa MA era oat hw SE eget ll a 
E a Batan ce ed ae ae 
a de fees docks den Gide Cih oy ba ra 
O eae aa vel e 
| | | | o — + — + — + — + — + — + — + —+— 
| | | | | | | | | | | | 
| | | | | | 1n1ail | | | 
| | | | | | 1m) Mm | | | | 
| | | | | | | | | lol | 
| | | | | | | | wl Lol 
| | | | | | 14141 | € 1 Oo 
| | | | | | IH IHI IUI 4 
| | | | | | | fy | i | I orwl 
| | IA I | | | | | IZII 
| | 1 ol | | IBH IHI inti ho 
| | IHIH | | ¡A | ee: ee ee | 
| | | | | I&II | | | 
al II wa OI«K«IQAIBHIAI lalala 
HIHI HI AIA HIHIHIMNI ODI lH IH I & 
Hlaslastata iy | Ql C | | LATNINnI 
10) l (e) l O l H ! H yn Q l El fy fy ! O | El l El El 
NH Ga Ea! Herm au 
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8.12.2 Transition Table 


I | Predicate Actions Output Events Next State 
o) 
A | Pl: 1/2 ESID (R=02) 
| F_ABORT_IND (R, AO=L) WF_NDISC 
| not P1: 1243 F_START_FILE_IND OPIP 
=-=-—+ Pl ri o a ql a e y a Ta al q ci a o is e q ii ii a Fa a q tao ci a ah a il Vi o a e a o a ES Ys a ie q a a) a Ys E 
B Da ESID (R=02) 
F_ABORT_IND (R, AO=L) WF_NDISC 
---+ = — SS Se ee Se SS SSS A SR ee SR A A SS SSS ee 
c | {72 F_CD_IND IDLESPCD 
---+ A AA A A as ae A a A AA A gy ee A Se ge A A AA A ee 
D | 1 F_ABORT_IND (Received 
| ESID Reason, AO=D) 
| N_DISC_RO IDLE 
==-—+ A A A E o te a e a e A A e o ds e a o il lad A a o e 
E | 4 F_EERP_IND 
| 8 See Note 2 
| RTR IDLELI 
——-+ A A A a ei man mh ea Sl ef ah A a ee y tl et a a a E A A ec E A al es e ay 
F 1 F_RELEASE_IND 
N_DISC_RO IDLE 
=-=-—+ o eE ras a a A ee tie 
G | F_EERP_IND 
| 8 See Note 2 
| RTR IDLELI 
——-+ HA A AA A AA A A AA ee A AA A A A mee A A A O ey er a tee 
H | P4: User Error UE 
| P2,not P4: 1,2 SFPA OPI 
| not (P2,P4): 1,2 SFNA IDLELI 
---+ A A mes ae a a a Na A a Sade A ab ae aa al Sl ey th jad a e yl ee al sd lll o eh el ai oe ee els Ad eh ee Pe 
I | P5: lye ESID (R=02) 
F_ABORT_IND (R, AO=L) WF_NDISC 
not (P5,P6): 1,2,5 F_DATA_IND OPI 
| not P5,P6: TD F_DATA_IND 
| 6,7 See Note 1 
| CDT OPI 
---+ HA AAA A A AAA A A A AAA A A a er a er eee AA ee ere eee ee 
J | 1,2 F_CLOSE_FILE_IND CLIP 
=-=-—+ SIA A E A A A RS SA A A ee A ee fe S 
K | P2,P3: 12 EFPA (CD-Req) WF_CD 
| P2,not P3: 1,2 EFPA (no CD) IDLELI 
| not P2: 1,2 EFNA IDLELI 
—---+ PA AA E nS ey Se I A A ey Oe A A A E SR me fey A a ee a ee eee ey ey ae A es 
U | User Error UE 
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8.12.3 Predicates and Actions. 


Predicate Pl: 


Note: 


Predicate P2: 


Predicate P3: 


Predicate P4: 


Predicate P5: 


Note: 


Predicate P6: 


Note: 


Action 1: 


Action 2: 


Action 3: 


Action 4: 


Action 5: 


Action 6: 


Action 7: 


Action 8: 


Note 1: 


Nash 


(I.SFID.Restart-pos > 0) AND (V.Restart = No) 
Invalid Start File command 
Positive Response 


I.F_CLOSE_FILE_RS (+) .Speaker = Yes 


I.F_START_FILE_RS (+) .Restart-pos > V.Restart 


V.Credit_L - 1 < 0 


Protocol Error because the Speaker has exceeded it’s 
available transmission credit. 


V.Credit_L - 1 = 0 


The Speaker’s credit must be reset before it can send 
further Data Exchange buffers. 


Stop inactivity timer. 
Start inactivity timer 


Build F_START_FILE_IND from I.SFID 
V.Restart-pos = I.SFID.Restart-pos 


Build F_EERP_IND from I.EERP 
V.Credit_L = V.Credit_L - 1 


Wait for sufficient resources to receive up to 
V.Window Data Exchange Buffers. 


V.Credit_L = V.Window 

Wait for resources required to process a new EERP. 
Flow control in case of reception. 

The ODETTE-FTP Listener must periodically send new 
credit to the Speaker. The timing of this operation 


will depend on: 


1. The User Monitor’s capacity the receive data. 
2. The number of buffers available to ODETTE-FTP. 


Informational [Page 67] 


RFC 2204 ODETTE File Transfer Protocol September 1997 


8. 


3. The Speaker’s available credit, which must be 
equal to zero. 


Note 2: Generally, the ODETTE-FTP Listener will send RTR 
immediately after receiving EERP. If required, it can 
delay the RTR until the resources required to process 
a new EERP are available. 


13 Example 


Consider an ODETTE-FTP entity that has sent a Start File (SFID) 
command and entered the Open Out Pending (OPOP) state. It’s response 
on receiving a Positive Answer (SFPA) is documented in Speaker State 
Table 1 which shows that transition 'K” should be applied and is 
interpreted as follows: 


if (I.SFPA.Restart-pos > V.Restart-pos) then 


begin // invalid restart 
Actions: Stop inactivity timer, // reset timer 
Start inactivity timer; 
Output: ESID(R=02), // to peer ODETTE-FTP 
F_ABORT_IND (R, AO=L) ; // to user monitor 
New State: WE_NDISC; 
end 
else begin 
Actions: Stop inactivity timer, // reset timer 


Start inactivity timer; 
Build F_START_FILE_CF (+) from I.SFPA 


V.Credit_S = V.Window // initialise credit 
Output: F_START_FILE_CF (+); // to user monitor 
New State: OPO; 


end 


The ODETTE-FTP checks the restart position in the received Start File 
Positive Answer (SFPA) command. If it is invalid it aborts the 
session by sending an End Session (ESID) command to it’s peer and an 
Abort indication (F_ABORT_IND) to it’s User Monitor. If the restart 
position is valid a Start File confirmation (F_START_FILE_CF) is 
built and sent to the User Monitor, the credit window is initialised 
and the Open Out (OPO) state is entered. 


Security Considerations 


ODETTE-FTP exchanges user identity and password information in clear 
text. It is therefore recommended that a lower layer (session, 
network or linkage) security protocol is used to protect the session 
from casual identity collection. 
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Virtual File Mapping Example 


This example demonstrates the mapping of a Virtual File into a 
sequence of ODETTE-FTP Data Exchange Buffers and shows how each 
Stream Transmission Buffer is built from an ODETTE-FTP Data Exchange 
Buffer prefixed by a Stream Transmission Header. 


Each line in this extract from ’The Hunting of the Snark’ by Lewis 
Carroll [SNARK] is considered to be a separate record ina file 
containing variable length records. Note that it does not represent 
a text file and CR/LF record separators are not used. The blank line 
is represented by a zero length record. 


"It’s a Snark!" was the sound that first came to their ears, 
And seemed almost too good to be true. 

Then followed a torrent of laughter and cheers: 
Then the ominous words "It’s a Boo-" 

Then, silence. Some fancied they heard in the air 

A weary and wandering sigh 

Then sounded like "-jum!" but the others declare 
It was only a breeze that went by. 


Assuming that the minimum exchange buffer length of 128 octets has 


been negotiated the result of mapping the text into Stream 
Transmission Buffers may be as follows. 


Stream Transmission Buffer 1 


Text ..-D."It’ s a Snark! " was the sound that first cam 
Hex-H 10084B2472 7262566762 2276727662 7676627667 2667772666 
Hex-L 00044C2947 30103E12B1 2071304850 3F5E404814 069234031D 
Key A a “iv Poems veneer, “Sree aN areas 
Text e to their ears,. .A nd seemed almost too good to b 
Hex-H 6276276667 26677242A4 6627666662 6666772766 2666627626 
Hex-L 504F048592 05123C5061 E40355D540 1CDF3404FF 07FF404F02 
Key A A WS A A AR A ees 
Text e true..Th en followe d a torren t 

Hex-H 6277762156 6626666676 6262767766 72 

Hex-L 504255E848 SEO6FCCE75 40104F225E 40 

Key a a a Sts ari ous 

Text ...-D.of l aughter an d cheers:. .Then the ominous w 
Hex-H 1007496626 6766767266 6266667734 2A56662766 2666667727 
Hex-L 000847F60C 157845201E 40385523A5 04485E0485 0OFD9EF5307 
Key AD a a a A Sab BAS ae 
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ords "It’s 
6767224727 
F243029473 


hey heard 
6672666762 
8590851240 


a Boo-".. 


Then, 


sile nce. 


Some 


September 1997 


fancied t 


262466228B 5666227666 6662225666 2666666627 
0102FFD202 485EC039C5 E35E003FD5 061E395404 


in the air 
6627662667 
9E04850192 


Stream Transmission Buffer 3 


Text 
Hex-H 
Hex-L 
Key 


Text 
Hex-H 
Hex-L 
Key 


Text 
Hex-H 
Hex-L 
Key 


Notes: 
Hex-H 
Hex-L 
Key: 


-D. .A 
1007442942 
0008450A10 


ke "-3um!" 
6622267622 
B502DA5D12 


breeze tha 
6766762766 
2255A50481 


weary and 
7667726662 
7512901E40 


but the o 
2677276626 
025404850F 


t went by. 
7276672672 
4075E4029E 


wandering 
7666676662 
71E4529E70 


thers decl 
7667726666 
485230453C 


High order bits of octet 
Low order bits of octet 


Stream Transmission Header 


sigh.Then 


sounded li 


7666B56662 7676666266 


39780485E0 3F51 


are. 


E4540C9 


.It w as only a 


67642A4727 6726667262 
1255029407 130FEC9010 


Data Exchange Buffer command code 'D” 
Subrecord header octet 
é Place holder 
All headers are represented with a period in the Text line. 


Each Data Exchange Buffer is preceded by a Stream Transmission 


Header. 


In the above mapping the first Data Exchange Buffer is 128 octets in 


length. 


The second Data Exchange Buffer 
finish at the end of a record. 
contained in the third buffer. 
the record as shown between the 


Buffers. 


Nash 


Informational 


The last record has been continued in the second buffer. 


has been truncated at 116 octets to 
The following record being completely 
This is an alternative to spanning 
first and second Data Exchange 
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The blank line has been encoded as a single header octet of ’80’ hex, 
indicating a zero length subrecord with the end of record flag set. 


The indented lines have been compressed. 
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September 1997 


ODETTE File Transfer Protocol 


RFC 2204 


ISO 646 Character Subset 


Appendix B. 


| | | | | | | | | | | | l | l | | | 
| la l | | | | l | | | | | | | | | | 
la l | `œ | | l | | | | | | | | | | | 
= | | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
— + — + — + ————— + —+—+—+4+—+—+—+—+—4+ —+ —+ —+ —+ —+ —+ —+— 
| | | | | | | | | | | | | | | | | | 
| LO Il | | | | | | | | | | | | | | | 
la l | Re} | | | | | | | | | | | | | | | 
dq | | | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
— + — + — gt tH He HH tH dH tH He tH tH —+ —+ —+ —+ —+— 
| | | | | | | | | | | | | | | | | | 
| l= l | | | | | | | | | | | | | | | | 
LoS il | Fo] AIQI Ø®ĞINIBIDIS>IZIXIXWXINI | | | 
=H | | l | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
Ht gt tH — aa dH He tH tH HH He tH —+ —+ —+ —+— 
| | | | | | | | | | | | | | | l | | 
| LO: 1 | | | | | | | | | | | | | | | 
1o | | st AEE = a I o a A DEA our al wal wivoul@winti Hy tuMtItHo!t sti gZgio 
=H | | | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
— + — + gt — tH — HH He dH dH dH He tH —+ —+ —+ — + —+ —+— 
| | | | | | | | | | | | | | | | | | 
| l= l | | | | | | | | | | | | | | | | 
|| | mM COlAINInMIitrtIininwl! rl alas | | | | | 
ol | | | | l | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
— + — + — + ————— + — tH —+—+4+—+—+—+—+—+4+—+ —+ —+ —+ —+ —+ —+— 
| | | | | | | | | | | | | | | | | | 
| 1 ol | | | | | | | | | | | | | | | 
I= l | N al | | | | | LS hel | | ¡ys IS 
© | | | wn | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
— + — + — gt dt He HH tH He tH He tH tH —+ —+ —+ — + —+— 
l | | | | | | | | | | | | | | | | | 
| LAW | | | | | | | | | | | | | | | | 
boil | qd | | | | | | | | | | | | | | 
ol | | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | | | 
— + — + — + ————— gt dH — tH He dH He tH tH dH Ht He dH —+ —+ —+ —+— 
| | | | | | | | | | | | | | | | | | 
| Io 11 | | | | | | | | | | | | | | | 
LESNI | o | | | | | | | l | | | | | | | 
ol | | | | | | | | | | | | | | | | | | 
| | | l l l l l l l l l l l l l l l 
— + — E E A Oo 
œ IIN | | | | | | | l | | | | | | | 
| COlAINInMIFI NI OIL rPIlLlaloalolrldtIinimiwttiw 
MHH | | | | | | | | | | Potlotoa lalate 
l l | | | | | | | | | | | | | | 
A Merit ta heel 
| qd COldAal!Old!Oldli old torn! orn t!ortrxn! old 
| | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| N STO- LA A Eo O e A i OO o e eA e O EOS A 
| | | | | | | | | | | | | | | | 
LH | | l | | | | | | | | | | | | 
1am MS E OD ES Oe SOG OS erat. tie) O St 
| | | | | | | | | | | | | | | | | 
| | | | | | | | | | | | | | | | 
| < oto!tlto!lo!lo!lo!lol E o A E = tal = A S E S a O E = S S = T E 
l | l l | l l | l l l | l l l l 
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